Estoy leyendo The Docker Book y siguiendo las indicaciones del Capítulo 5, he creado mi primera imagen con Docker. Mi imagen de prueba se basa en armbuild/debian -en el libro se usa Ubuntu14:04- sobre el que se instala Nginx.
La creación de la imagen me ha enseñado algunas cosas interesantes: la primera, que debido al funcionamiento de Docker, el proceso principal no puede ser un demonio (lo que sería un servicio en Windows). Los contenedores sólo se ejecutan mientras el proceso lanzado está activo. Para convertir un proceso en un demonio en Linux, se forkea el proceso principal en un proceso en segundo plano y se mata el proceso lanzado con la consola. Pero eso hace que Docker finalice el contenedor... Así que hay que lanzar Nginx con el parámetro daemon off, que ejecuta Nginx como un proceso.
Segundo, que Docker cachea los contenedores intermedios que no cambian de una ejecución del comando docker build a otra, por lo que el proceso de refinamiento de la imagen final es bastante rápido. Esto lo he descubierto por las malas, ya que he cometido algunos errores al copiar los ficheros de configuración de Nginx.
Otro detalle es que como el contenedor final se lanza en segundo plano (con el parámetro -d), cualquier error en la configuración que impida que Nginx arranque con normalidad no se muestra por ningún lado: el contenedor arranca, el proceso de Nginx no arranca, y el contenedor finaliza con éxito. Hasta que no he ejecutado el contenedor en modo interactivo (con -i -t) no he visto los errores en la configuración de Nginx :(
Otro detalle interesante ha sido la aparición de los volúmenes, que aunque todavía no se han explicado en el libro, viene a ser un montaje de una carpeta local en el contenedor final, lo que permite saltarse el sistema de capas en modo "sólo lectura" y modificar datos de manera persistente fuera del contenedor. Los datos de los volúmenes no se incluyen en la imagen o en el contenedor.
El tema de la persistencia de los datos en los contenedores era algo que me preocupaba y que ahora veo que está resuelto mediante este mapeo de rutas locales en rutas virtuales en el contenedor.
En el ejemplo del libro se conecta una carpeta local donde residen los ficheros de la web que se está testeando con la ruta publicada de los documentos estáticos en Nginx (/var/www/html/), de manera que podemos utilizar el servidor Nginx en el contenedor para testear el sitio web a medida que lo vamos modificando, simplemente recargando la página en el navegador.
Quizás no es el montaje más eficiente del mundo, pero siendo un ejemplo sencillo, demuestra cómo ir definiendo las diferentes acciones en el Dockerfile, la construcción de la imagen y cómo ejecutar un contenedor con un volumen conectado. Además del debugging que he tenido que hacer para conseguir que funcionara.
A partir de aquí, el límite lo pone la imaginación. Por un lado, puedo mover el wiki (servidor web, PHP y Dokuwiki) a un contenedor, montando el contenido a través de un volumen. Uno de los siguiente proyectos de Raspberry Pi Admin será el montar un NAS o un servidor de ficheros, por lo que si coloco los datos del wiki podría lanzarme a utilizar varios frontales (un par) y un balanceador frente a ellos.
Una vez abierta la posibilidad de usar Docker para lanzar aplicaciones aisladas -o en conjunto- sin necesidad de realizar cambios en el sistema operativo de la RPi, espero poder avanzar con mayor agilidad en la creación de escenarios "profesionales" con la RPi. Si sólo tuviera algo más de tiempo libre ;)
Comentarios